Release 10.1A: OpenEdge Development:
ProDataSets

GET-CHANGES method

The GET-CHANGES method extracts the changes for you into a second ProDataSet, normally one that you have just created using the CREATE-LIKE method. However, there is nothing to prevent you from defining two equivalent ProDataSets statically and using GET-CHANGES to move changes from one to the other. If the target ProDataSet is static, it must contain temp-tables whose field definitions are the same at least in field data type, extent, and order. The temp-table index and Data-Relation definitions do not need to match between the ProDataSets, but the fields of the temp-tables must match in name, order, data type, and extent.

We call the result of a GET-CHANGES method a change ProDataSet. We refer to the original ProDataSet that acts as the source for the change ProDataSet the origin ProDataSet.

GET-CHANGES uses the handles of the two ProDataSets, just as CREATE-LIKE does. For example:

Syntax

change-dataset-handle:GET-CHANGES( origin-dataset-handle ).

GET-CHANGES effectively does the following for each temp-table in the origin-dataset for which there is a before-table:

For each row in the before-table, create a row in the before-table of the change-dataset and buffer-copy the origin-dataset row into the change-dataset.
For each before-table row that is not for a delete, locate the row in the after-table of the origin-dataset that is paired with the row in the before-table (using the AFTER-ROWID attribute), create a row in the after-table in the change-dataset, and buffer copy the origin-dataset row to the change-dataset table.
Set the ROW-STATE of the change-dataset row to the ROW-STATE of the origin-dataset row in the target-dataset before-table, and if applicable, the after-table.
Save the RowID of the before-table record in the origin-dataset as an attribute, called ORIGIN-ROWID, of the same row in the change-dataset. This can be used later to allow the final versions of changed rows to be merged into the original origin-dataset.

As the examples in Chapter 10 "Advanced Update Operations" show, your procedure can then pass the target dynamic ProDataSet as an INPUT-OUTPUT parameter to the server-side procedure, get back the final versions of any records further changed on the server, and merge them back into the original ProDataSet, using the MERGE-CHANGES method.

If you want to include the parent row of each changed child row in the ProDataSet object or ProDataSet temp-table, use the optional get-parent-mode expression:

Syntax

change-dataset-handle:GET-CHANGES(origin-dataset-handle     [, get-parent-mode ] ).

If there is more than one parent level above the changed row, Progress includes the parent row at each level. In this case, the parent temp-tables must have a unique primary index that Progress can use to find the corresponding rows. If a parent row has changed, Progress copies both the before-image and after-image of the parent row. If a parent row has not changed, there is no before-image of the parent row, and its change state (ROW-STATE) is ROW-UNMODIFIED (0) or the Unknown value (?). When the relation mode of a parent is REPOSITION, no attempt is made to find that parent.

When this expression is FALSE, Progress does not include parent rows. The default value is FALSE.

The ProDataSet objects associated with the change-handle and original-handle must have the same number of temp-table buffers, and the definition of the corresponding temp-tables must match (that is, in the number of columns, data types, and so on).

Once the changed rows are loaded, Progress sets the ORIGIN-HANDLE attribute on the temp-tables in the receiving ProDataSet object to the corresponding temp-tables in the original source ProDataSet object. Progress also sets the ORIGIN-ROWID attribute on each of the before-image table rows created in the receiving ProDataSet object to the ROWID of the corresponding before-image table row in the original source temp-table. The MERGE-CHANGES and MERGE-ROW-CHANGES methods use these values to match up temp-tables and temp-table rows during a merge operation.